The present invention relates to the field of user interface controls and in particular to a scroll bar.
A User Interface (UI) allows users of a computer system to interact with a computer application program, by using graphical elements to represent the application information and actions available to a user. The actions are usually performed through direct manipulation by a user of displayed graphical elements called controls, or widgets.
A computer application is often allocated an area of a display screen in which it can display all or part of the application's presentation content, such as a web page, email message, or drawing, for example. When the dimensions of the application presentation space are larger in the horizontal and/or vertical direction than those of the on-screen viewing area assigned to the application, a scroll bar is displayed. The scroll bar provides a mechanism whereby the visible portion of the presentation space can be selected.
The viewing area is often provided within a view window, which provides a frame or container for the main presentation content, and which can be resized, moved, hidden, restored, and closed as desired. The scroll bar is used to manipulate the region of the presentation space which is visible through the view window and also to indicate the location of the data displayed in the window relative to the whole presentation space.
A cursor control device, such as a mouse or trackball device, can be used to control the scroll bar. As shown in FIGS. 1a and 1b, a scroll bar control 10 is usually designed as a longitudinal bar 14 along on one or two sides of a view window 18, each containing a thumb button 16. Typically, a user can manipulate the displayed view by dragging the thumb button to some position in the scroll bar control. Alternatively, the user scrolls up/down a view incrementally in units of a row/column or in larger units, such as page size or the horizontal/vertical view dimension, by clicking on the bar on either side of the thumb. A scroll bar control typically also includes scroll buttons 15 at each end of the scroll bar, which allow a user to scroll up/down or left/right (by units using single mouse clicks or continuously by holding down the scroll button) through the presentation space. This provides a rapid and efficient method for the user to vertically and/or horizontally scroll the window through the presentation space.
In the case of a horizontal scroll bar control, the thumb button can be moved horizontally between a left bound (conventionally, the minimum position) and a right bound (conventionally, the maximum position). Similarly, in the case of a vertical scroll bar control, the thumb button can move vertically between a lower bound (conventionally the bottom or minimum position) and an upper bound (conventionally the top-most or maximum position).
In modern scrollbars, the size of the thumb button often indicates a ratio of the size of the visible display area (or amount of visible data) to the size of the application presentation space (or amount of total available data), and the position of the thumb button along the scrollbar indicates the location of the area of the presentation space (or portion of the data) which is being displayed.
For example, suppose a UI is being used to present a list of thirty data items to a user, but there is only enough on-screen space to list fourteen of these. FIG. 1a shows how the ratio of visible to available data is typically conveyed to the user as a ratio of the thumb button size (x) to the total bar length (y). So, in FIG. 1a, x/y=14/30.
FIG. 1b shows how the items displayed in the window change when the thumb button is moved. The top edge of the thumb button 16 has been moved a distance a from the top of the scrollbar. In FIG. 1b the top of the thumb button is now 1/3 of the way along the scrollbar length, that is a/y=1/3, so the topmost item in the view is item 30/3=10. The size (x) of the button 16 remains unaltered being a ratio of 14/30 of the bar length because the amount of available data remains the same as in FIG. 1a. 
A problem is encountered in the scenario where the user interface is being used to control data that is being populated asynchronously and the application makes the data available for display as it is received, that is before the full set of data has been retrieved. This occurs in situations where there is delay in the data being made available, such as displaying a set of data from a server where retrieval over a network has some kind of latency, where the data becomes available in discrete portions, such as files or pages, or any kind of processing where a significant time is taken between data items being added to the available data set. In such scenarios, rather than wait until all of the items are known before making the list available to the user, there is a benefit in showing the user the available data, and updating the display as updates are received. This has the advantage that the user can begin working with data items as they become individually available allowing them to continue working as the program asynchronously adds more items. However, because the size of available data, such as number of rows, is increasing over time this has the consequence that the size of the scrollbar thumb button decreases to reflect the new ratio of visible items/available items, and also that if the thumb button is not at the top of the scrollbar, the thumb button may also move upwards as the relative location of the visible data also changes.
This is illustrated in FIGS. 2a, 2b and 2c which show the progression over time of the display of a list of items, first with 15 available items, then 30, and finally 45. In each situation the thumb button size is different because the number of available items (rows) has changed. When there are 15 items in the list (FIG. 2a) the ratio x/y=14/15, and then later 30 items (FIG. 2b) the ratio x/y=14/30. FIG. 2c shows that as time continues to progress, the thumb button size continues to shrink, and with 45 items in total the ratio x/y is just 14/45. This situation makes the list difficult to operate for the user. If the list is in the state shown in FIG. 2a and the user selects the thumb button ready to move it and scroll the list, because the thumb button is dynamically decreasing in size as the application is adding more rows, the thumb button is a moving target. Also as more rows are added the relative locations of the displayed data items to others in the list changes. This may lead to the thumb button moving along the scrollbar, as well as changing in size. Furthermore, when the user wishes to scroll to a different view, the user is unable to determine the position to which the thumb button should be moved in order to make visible the required portion of the data as the relative locations represented by positions along the scroll bar keep changing.
Another problem is that the user has no way of knowing when the list is complete because the application is adding items in the background. Prior art methods for overcoming this problem add another kind of indicator to the UI, an animated graphic, such as a progress bar, whose state changes to show that activity is occurring, and which is found in web browsers, busy cursors, and so forth. These have the disadvantage of being somewhere else on the UI, so they are not directly in front of the user looking at and working with the list, and can be confusing for a user if there are two or more view windows, each requiring a progress indicator. A solution in some applications is not to show the user the partially available list items and wait until the entire retrieval task is complete, however this suffers from poor usability because it prevents the user from starting working with the items as they become available and slows down perceived response time as the user has to wait for longer periods before being able to see and work with data.